Repairing the Domain Trust Relationship Between Workstation and Active Directory

If a trust relationship between a Windows workstation and an Active Directory domain is broken, the computer won’t be able to establish a secure channel with the domain controller, and domain users will not be able to authenticate to that computer. In this article, we will look at the root causes of why Windows machines can fall off the AD domain and a simple way to restore a trust relationship between a computer and a domain without reboot.

If a computer is not in a trust relationship with a domain, you will get an error when you try to log on to that computer as a domain user:

The error may also look like this:

Typically, administrators in this situation simply remove the computer from the domain and rejoin it to AD. This method works well but requires a lot of time and several computer restarts. It’s much faster and easier to restore the trust relationship between the workstation and the domain using PowerShell (without rejoining the domain or restarting the computer).

To restore trust between the machine and the domain, you need to log on to the computer locally using any account with local administrator privileges. This can be a local user with administrator permissions, or the built-in Windows administrator (if you don’t know your local administrator password, you can reset it).

To log on to the computer as a local user, enter the local user name on the sign-in screen in the format: .\localuser . The dot at the beginning of the name indicates that the local account database should be used.

Open an elevated PowerShell console and check to see if the computer is in a trust relationship with the AD domain:

Test-ComputerSecureChannel –Verbose

The computer cannot establish trust with the domain if the computer’s local password and the domain password do not match and the command will return:

To force restore the trust relationship between the current workstation and the domain, run the following command:

Test-ComputerSecureChannel -Repair -Credential woshub\administrator -Verbose

If the computer can connect to the DC and set a new password for its account, thereby restoring trust with AD, a message will be displayed:

Check that trust has been successfully restored. Run Test-ComputerSecureChannel again to make sure it returns:

Log off the local user and sign in to the computer as a domain user (no reboot required).

You can also use this command to force reset and sync your computer’s password.:

Reset-ComputerMachinePassword -Server mun-dc01.woshub.com -Credential woshub\administrator

mun-dc01.woshub.com – is the name of the closest DC.

In some cases, the trust repair command may return an error:

In this case, you need to check that the domain can be connected from the computer, that this computer account exists in the domain, that it is not disabled, and that you have the permissions to manage it. To find out the name of your computer, use the hostname command. Open the Active Directory Users and Computers snap-in (dsa.msc) and find the account for this computer. In this example, it is disabled. Re-enable it.

Why is it possible for the trust relationship between a computer and a domain to fail?

When a computer is joined to an Active Directory domain, a separate computer account is created for it. Each computer in the domain has its own password, which is used to authenticate to the domain and establish a trusted connection with the domain controller. By default, this password changes automatically every 30 days and is stored locally on the computer (under the registry key HKLM\SECURITY\Policy\Secrets\$machine.ACC) and in the AD. The frequency of computer password changes is set by the Domain member: Maximum machine account password age GPO option.

Unlike user passwords, the computer password doesn’t expire. The computer, not the domain controller, initiates the password change.

If the hash of the password that the computer sends to the domain controller doesn’t match the computer’s account password in the AD, it won’t be able to establish a secure connection to the DC and will return a trust relationship error.

The most common reasons that cause the failed trust relationship error:

For test VMs that need to be frequently restored from snapshots or restore points, you can use the GPO parameter to disable regular password changes (Domain member: Disable machine account password changes in Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options).